-
Notifications
You must be signed in to change notification settings - Fork 23
feat(spec-tests): implement type spec tests #417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently blocked on #416 getting merged in |
…igp#448) We have many hardcoded paths all over the codebase. Move all of them and directory creation to a `data_dir` module in global config. There we can also soon add a lockfile mechanism!
…atabase switchups (sigp#387) - closes sigp#357 Introduce the `metadata` table where we track the currently used database schema. This will later allow us to implement "migrations", i.e. updating the database schema without requiring the user to resync. Furthermore, when we create the database, we store the domain type used in order to avoid working with a database that exists, but was previously used on another network. The existing `block` table is removed and it's column moved to `metadata` in order to have only one table with data that exists only once.
- sigp#471 This was caused by a bug in `multi_index_map`, see also lun3x/multi_index_map#65. Due to time pressure, revert the refactor sigp#463 for now for a smooth `v0.3.0` (and by extension `v1.0.0`) release.
This adds a CLAUDE.md file that provides guidance to Claude Code when working with this repository. The file includes: - Common commands for building, testing, and linting - Architecture overview - Code organization details - Development tips 🤖 Generated with [Claude Code](https://claude.ai/code)
) I noticed a fun bug: When in a single batch (for historic sync) or block (for live sync) a validator is removed and readded again, the validator store does not notice the change. This is bad, as the private key share likely has changed. So we continue signing stuff with the old partial share, while correct nodes sign with the new partial share. This causes signatures to be invalid when recombined. First, I was tempted to fix this while maintaining the current structure, but I realized that iterating over the whole database every time and comparing it to everything in the validator store is quite nonsensical if we can use the database directly instead. So this PR gets rid of the `DashMap`s in the validator store and reads needed info directly from the database state.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implementation for the types spec tests. Gave myself a week for these and think it may be time to just clean this all up and call them good. This PR contains the work in #374 and #377 as everything got a bit our of line so I decided to just merge everything together. This is a giga PR so I can also try to break it up.
I would say the main use for these is to test our SSZ encoding/decoding, which we can now confirm is spec compliant. There really may even be an argument that we should only include the ssz encoding/decoding and consider what we can scrap.
I have also deemed a few to be skippable
There are also some tests with data issues that I have raised
- The ssv message tests use message ids that should not be considered valid for the testing scenario. I have addresses this hereBeaconBlock
, fails withBLST_BAD_ENCODING
. Raised the issue here